I started working on adapting the Kata CI scripts to install from this operator. I will be trying to re-use the scripts in tests/e2e/ as much as possible, for example, tests/e2e/operator.sh install to install and check Kata Containers in the cluster's nodes. So far I faced two problems with operator.sh though:

1. one cannot overwrite the default kata-payload image. And it will be needed to point the operator to the image built by the kata CI, if it runs in a pull-request triggered job;
2. likewise one cannot overwirte the operator controller and reqs-payload images. For those images there is an extra problem which is operator.sh uses the built-and-pushed-to-local-registry images so it always tries to start a local registry service. If it is installing from quay.io (or ghcr.io), for example, it makes no sense the local registry.

So this PR address those two problems. Also by making operator.sh more flexible, this will likely to solve issues when we start improving the operator CI pipeline as suggested in #309

If that helps on review, here goes a sample of the code I'm writing for the Kata CI side:

function install_coco_operator() {
	local repo

	repo=$(get_from_kata_deps "externals.coco-operator.url")
	if [ -f "$COCO_OPERATOR_DIR" ]; then
		rm -rf "$COCO_OPERATOR_DIR"
	fi
	git clone "$repo" "$COCO_OPERATOR_DIR"
	pushd "$COCO_OPERATOR_DIR"
		# Let's install the kustomize tool if not present.
		make kustomize
		echo "::group::Install operator"
		PATH="$PATH:${PWD}/bin" echo "./tests/e2e/operator.sh install"
		echo "::endgroup::"
	popd
}

I tested locally by running:

$ IMG="quay.io/confidential-containers/operator:latest" \
PRE_INSTALL_IMG="quay.io/confidential-containers/reqs-payload:latest" \
KATA_PAYLOAD_IMG="quay.io/kata-containers/kata-deploy-ci:kata-containers-latest" \
PATH=$PATH:${PWD}/bin \
./tests/e2e/operator.sh install